perm filename PLAYER[P,JRA]4 blob sn#426209 filedate 1979-03-10 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00006 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	byte lisp setup
C00008 00003
C00012 00004
C00015 00005
C00024 00006
C00027 ENDMK
C⊗;
byte lisp setup

J allen  		general introduction in spirit of anatomy condensed
			   (see next page)

G prini  		implementation of scheme system for Z-80 system

David Stoutmeyer 	8080 lisp with applications to macsyma
	they have a small lisp running mainly to support
	an algebraic manipulation system for high school kids. quite impressive,
	has bignums but no funargs - shallow binding. they were running with 48k.
 	he was very interested
	in 8080 vlisp as he didn't know about it. Dr. Dobbs were here chasing hin up
	for an article about his system (will distribute for about $70in a month or so).
	i told him about your attempts to round up some good lisp articles for a special
	issue of byte and he told me he would contact you about it either by phone
	or over the net. he seemed to prefer appearing in your lisp special to Dr. Dobbs.
	he is writing a book on algebraic manipulation.   peter

	PETER MILNE TOLD ME THAT YOU ARE EDITING A SPECIAL ISSUE OF
	BYTE, DEVOTED TO LISP.  A COLLEAGUE OF MINE, AL RICH,
	IMPLEMENTED A TINY LISP FOR THE 8080.  IS IT TOO LATE
	FOR HIM TO SUBMIT AN ARTICLE?  IF NOT, COULD  YOU TELL ME THE DEADLINES AND
	THE EDITORIAL GUIDELINES?

William Kornfeld  	pattern directed invocation
	I am finishing up a master's thsis on a pattern directed invocation
	system implemented on top of Lisp (ala Planner, Conniver, etc.).
	These languages make heavy use of list structure and would be a
	good example of the extensibility of Lisp.  I would be interested
	in writing an article on what pattern directed languages are, what
	what they are used for, and how they can be implemented in Lisp.

Phil Agre		functions in lisp --phil and hacks
	       I am in the process of preparing an article on the implementation
	of functions in LISP, half philosophy-of-LISP, half assembly-language
	coding hacks, which comes in 20- and 50- double-spaced-page versions.
	It will appear this month (w/ luck) as a Univ. of Maryland Technical
	Report under the title "Functions as Data Objects -- The Implementation
	of Functions in LISP".  Would you be interested in receiving a copy
	of this report with an eye towards publishing it or a version of it
	(e.g., the philosophy half or the hacking half) in the August '79
	LISP issue of BYTE?  

Vaughan Pratt		theoretician looks at lisp
	For Byte I would be willing to talk (a) about the contribution made to
	LISP by mathematical logic and realted stuff (b) how syntax is a red
	herring to some extent in that LISP syntax and LISP semantics can
	be cleanly separated and the latter is more interesting, (c) what
	a theorist like me finds useful about LISP in practical programming,
	and/or (d) what features of LISP and APL could be elegantly combined
	to form a more winning language.  I'm unqualified to talk about
	history, and not particularly anxious to talk about implementation
	issues - how to do it, who's done it, what they did, etc.


H. Baker		garbage collection
	I'd love to submit an article on (what else?) garbage collection!
	What's the scoop?

r zippel, inc		architecture
	This is to inform you that some subset of us will be submitting a
	paper for the August issue of BYTE.  The title will probably be
	something like "LIL - A Lisp Implementation Language". We will
	present a Lisp based compiler for implementing system software.
	With the language (compiler and perhaps interpreter) embedded in
	a Lisp-like environment, the user will have access to the Lisp
	debugging tools.  We feel that the ability to manipulate programs
	via macros coded in Lisp will speed the code writing phase.  This
	language should be usable on micro-processors without difficulty.


efficiency


ach
gls
rg?

lisp
 spaces
  atoms
     plist[pname, value cell, doc pointer, property list]

   numbers
  lists
  strings
  arrays (?)
  primitive/compiled
  frames(?)

compiler
 generate psuedo-code for porting
 assembler and fasload

editor
 screen oriented
  ()-blinkers
  structure sensitive
  output driven by types

debugger
 screen oriented
  graphic machine description

virtual memory
 floppy/hard memeory
  hardware support
   segmented procedures
   data areas

interface
 hardware
  sail keyboard
  mouse (?)
 software
  immediate help with doc on-line, accessible either directly or @atom.
   
The compiler, editor, and debugger are all written in lisp.  The  strategy
should be to consolidate what is known, leaving invention for version 2.

March: Intensive search, refinement, and discussion of features for editor
       and debugger.  Timing tests for VM schemes and feasibility of fancy
       storage managers  (think dual  processor?  --on-board  gc).  
	
       Examine pseudo-code/target  machine  hacks;  need  balance  between
       porting and speed with speed critical for version 1.

April-
August:Several activities  can occur  in parallel,  however may  be  worth
       having two machines available so low-level VM-interface development
       doesn't  disturb  systems  development  and  documentation   phases
       (tempers will get short!!)  Basically write code with BOTH hands!!


Sept:  Intensive QA, and as much guinea-pigging as possible.

For our effort, we  will have the best  micro-editor available; with  some
very interesting hardware coming over  the hill. The hardware  integration
and support will  be done  by a  very competent  group, knowledgeable  and
SYMPATHETIC to lisp.

It is difficult to judge how much effort is involved in each piece,  since
we're not  building pieces;  that's  why the  March  effort is  of  utmost
importance. Given that we find the proper "seams", I'd guess the following
relative order of difficulty and importance:

 AREA	    DIFFICULTY     IMPORTANCE
compiler	1.	      .3
virtual mem	.95	      .7
debugger	.7	      1.
editor		.5	      1.
documentation	.2	      1.


data -driven compiler


e.g.  to compile while

atom for while has
[compile . while_compile]  property pair


(COMP EXP DEST SLOTLIST)
      (COND ((ATOM EXP) (COND ((CONST EXP) (COND ((SLOTTED CONST))
						 (T (EMIT EXP DEST)
						     (SLOT CONST DEST))))
			      ((VAR EXP) (COND ((SLOTED EXP))
					       (T (EMIT EXP DEST)
						  (SLOT EXP DEST))))))

	    (T((GET (FIRST EXP) 'COMPILE) (REST EXP) SLOTLIST))))


(EVAL EXP DEST ENV)
      (COND ((ATOM EXP) (COND ((CONST EXP) (SEND (DENOTE CONST) DEST)) 

			      ((VAR EXP) (SEND (LOOKUP VAR ENV) DEST))

	    (T((GET (FIRST EXP) 'EVALUATE) (REST EXP) DEST ENV))))


exp 	const
	var
	cond
	while
	prog1
	progn
	fn-call
	prim-call
	...

while 	<p> {<exp>}

cond {<p> <exp>}

ex. (to compile while  [gensym→L; 
			compile<p>→A; 
			compile[(cond ((null A) (go (gensym)→L1))]
			compile {<exp>}
			compile[(go L)]
			L1 ]


    (to evaluate while [gensym→L; 
			evaluate <e> →A;
			evaluate[(cond ((null A) (go (gensym)→L1))]
	*better*	if null A (go (gensym)→L1);
			evaluate {<exp>}
			evaluate[(go L)]
			L1 ]





(to compile cond (gensym→L)
	         {if null[cond]→L; exit;
		  compile <p>→A;
		  compile[if((null A) (go (gensym)→L1))]
		  compile <exp>
		  compile[(go L)]
		  L1
		  decr[cond]}
		  




(to evaluate cond { 	if null[cond] err[]
			evaluate <p>→A
			if A evaluate <exp>;exit
			decr cond}



(to evaluate 	fsubr jump @linker			eg (IF t1 t2 t3)

(to evaluate	subr	 length[subr] ≠ args[subr] →loss
			 if null[subr] jmp @linker
			 alloc_frame →dest
		      	 evaluate {<exp>}
			 link dest env
			 jump @linker


(to compile 	expr
		fexpr
		macro




(DEFUN FEXPR TO (L)
	(PUTPROP 

cheapy
1. mcgraw-hill book and consulting
2. lisp for hard disc from alpha
3. hardware from western digital
4. applications
5. mod2
6. plm's

This document  outlines  a  minimum  risk plan  to  develop  a  basis  for
artificial intelligence packages. It is based on an essentially one-person
part-time effort, each step presupposing  the existence (and success!)  of
the previous.

The corner  stone  of this  effort  is  the existence  of  a  satisfactory
"development" machine.  "Development"  is  meant  both  in  the  sense  of
document production  and  program  production.  The  initial  proposal  to
McGraw-Hill, dated Jan 7, 1979, asks for their support in purchasing  such
a system in return for the  preparation of an introductory LISP book.   In
essence, the argument to them states that LISP's popularity is growing and
that the introductory book  can perform a service  similar to that of  Ken
Bowles' book, "Problem Solving in Pascal".  Specifically, the  forthcoming
BYTE issues and "Anatomy of LISP"  make LISP details available to a  wider
audience.  The  interest  in   artificial  intelligence  applications   of
computing is already there; witness the BYTE readership; witness the heavy
investment by  TI  in  AI,  and  the  growing  concern  from  conservative
companies like HP.

The remainder of my argument to them involved my service to their staff on
the appropriate ways for a publishing concern to prepare for the computer.
The publishing  industry  is  archaic;  their  procedures  for  processing
manuscripts have only marginally been  affected by the computer.  Since  I
have been "through the mill" with them, I  feel that there is a lot I  can
tell them about modern document preparation.

A secondary  concern for  their  consideration was  my  offer to  build  a
demonstration document production  system within the  process of  creating
their text.  That  system  will have  significant  marketable  value  when
transported to a new generation micro-processor.

Basically the  offer  to McGraw-Hill  asks  for a  manuscript  preparation
grant, sufficient to develop facilities for their text. Once that text  is
produced, the  facilities become  mine. However,  while that  contract  is
running I expect  to pursue additional  avenues. First, the  text will  be
geared to the existence of a "standard" LISP system, much in the spirit of
USCD Pascal.  It should  be advantageous  for a  manufacturer of  personal
computers to possess  this LISP.  In particular, the  manufacturer of  the
development machine used in  the book production  should be interested  in
supporting my efforts; support should include hardware, software, and some
reasonable amount of money. In  turn, they would have  a jump on the  LISP
market.

Midstream in this project, a hardware effort should begin to settle on  an
inexpensive architecture for a  LISP machine; either  a L-code machine  in
the spirit  of  the  "Pascal micro-engine"  or,  depending  on  economics,
perhaps an interpreter running on one of the new microprocessors.

In either case, towards  the end of this  project sufficient capital  such
have accrued that applications of the document preparation tools, of LISP,
and of the hardware can begin  to surface. Completed packages should  come
first; they  will involve  applications  of AI  to business  and  personal
areas. For  example,  subsets on  natural  language for  communication  of
requests to  the machine.  As stated  eariler, the  more mundane  document
productions facilities can also be exploited.  Also, the LISP base can  be
exploited for building non-LISP applications;  since LISP is an  excellent
systems-building tool the speedy development  of languages such as  Pascal
and Modula dialects  should be possible.   Later the development  machines
can be marketed, but initially they should remain controlled.

This scheme is built on the gradual expansion of a controllable base.  Its
advantage is  clear:  except  for  the book,  all  other  efforts  can  be
terminated without financial  loss. The  scheme also  has weaknesses:   in
particular, it  is streached  out  over several  years, being  a  definite
part-time effort  at least  at the  inception. It  is not  clear that  the
maximally profitable window for such products will remain open this  long.
The technology is spreading rapidly; so there is unquestionable benefit in
being first with the combination of new software and new hardware.


grand
0. tools 11xZ
1. lisp
2. mod(2)
3. applications
4. plm's

This proposal assumes that sufficient capital is available immediately  to
begin the development  of AI  related computer  goods. As  with the  other
proposal, several interesting and profitable objects can be produced along
the way, but the trust of this  effort is the immediate production of  the
new systems.  The proposal assumes the immediate acquisition of a  machine
at least comparable to that  of the graduated proposal; better  facilities
would mean faster  development and  additional cost.  Careful study  would
need to be made of the trade-offs.

The major purpose of the development machine is to act as a software  base
to supply the  new processor.  Only the tools  which are  needed for  this
effort would  be developed  on the  host. The  idea is  to get  first-rate
software available on the new processor  as soon as possible. This  effort
 would probably  cover the  cost of  the development  effort all  by
itself, since it  may be  several years  before quality  software will  be
forthcoming from the manufacturers.

The software which is spunoff at this  time would be of high quality,  but
of a  rather  pedestrian  type:  perhaps Modula  (if  that  is  a  popular
commodity), surrounded  with  quality  program  and  document  development
tools. This effort can be encapsulated and maintained by a suparate branch
while development  continues  on  capturing  the  artificial  intelligence
technology.

The major goal is a transfer of artifical intelligence research into
the business and consumer marketplace. One particularly attractive  application
is  the packaging of an acceptable subset of natural language as a
computer query and command language. Within well-defined "expert domains"
such